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INTERNET DOCUMENT MANAGEMENT 
SYSTEM AND METHODS 

FIELD OF THE INVENTION 5 

This invention relates to apparatus and methods for man- 
aging electronic documents over open networks, such as the 
Internet, to permit users to store, retrieve, and collabora- 
tively manipulate files. 

10 

BACKGROUND OF THE INVENTION 

Document management systems are known that permit 
multiple users to store and retrieve electronic documents on 
a closed client/server architecture network, such as a local 
area network or wide area network. These previously known 
document management systems, such as DOCSFusion, 
available from PCDOCS, Inc., Toronto, Ontario, Canada and 
EDMS 98, available from Documentum, Inc., Pleasanton, 
Calif., require the presence of a client application on each 
node of the network that is to access and manipulate files. 20 

With the recent rapid expansion of the Internet, the 
opportunity for collaborative efforts has increased many 
fold, as colleagues scattered around the world can rapidly 
transmit files for review and revision using electronic mail 25 
facilities. While electronic mail systems are useful for 
transmitting relatively small files on the Internet, however, 
large documents often are too large to be handled by typical 
message transfer systems, and can overburden a network. 
Large documents also may exceed the available storage at a 3Q 
recipient's site, thus preventing a recipient from storing a 
received document. Electronic mail systems used on open 
systems, such as the Internet, also do not generally address 
security concerns, or permit a transmission to be tracked, as 
is possible with a physical document delivery service (e.g., 3S 
courier). 

Smith U.S. Pat. No. 5,790,790 describes an Internet 
electronic document delivery system, wherein an e-mail 
message contains a direct reference (i.e., a Uniform 
Resource Locator or "URL") to an electronic document ^ 
stored on a server. When a recipient receives the e-mail 
message, the direct reference is used to access the document. 
A drawback of the system described in that patent, is that the 
sending computer must include a specialized client applica- 
tion for interacting with the server. The system described in 45 
that patent also lacks the kinds of transaction logging and 
accounting functions needed to provide a useful document 
management system. 

The POSTA® system, offered by Tumbleweed Software 
Corporation, Redwood City, Calif., overcomes some of the 50 
drawbacks of the system described in the foregoing patent. 
For example, the POSTA® system eliminates the need for 
specialized client software for basic document delivery 
operations, and permits the use of a previously known web 
browser, such as Internet Explorer 4.0®, available from 55 
Microsoft Corp., Redmond, Wash., or Netscape Navigator®, 
Netscape Corporation, Mountain View, Calif. That commer- 
cial system also eliminates use of the direct reference in the 
e-mail message, instead providing a URL for a webpage that 
provides the user with several options for document deliv- 60 
ery. The system provides none of the capabilities normally 
associated with a document management system. 

Higley U.S. Pat. No. 5,790,793, like the foregoing Smith 
patent, also describes an Internet electronic document deliv- 
ery system wherein an e-mail message includes a URL 65 
reference to a document stored in a server. This system 
described in this patent also requires the use of a specialized 



,466 Bl 

2 

client application, and is limited to an electronic document 
delivery service. 

While it is known in the art to use an Internet web browser 
to download an electronic document from a website, using, 
for example, Hyper Text Transfer Protocol ("HTTP") or File 
Transfer Protocol ("FTP"), there currently do not exist 
document management systems that permit such a file to be 
modified by a user, and uploaded to the system for further 
collaborative retrieval and modification by others. 

In view of the foregoing it would be desirable to provide 
a document management system and methods that permit 
electronic documents to be made available for use on open 
systems, such as the Internet, and to be accessed using a 
previously known web browser — without the need for a 
specialized client application. 

It also would be desirable to provide an Internet-based 
document management system and methods that permit 
users to access a plurality of services supported by a 
common Internet-based database, including document 
storage, collaborative file sharing and workflow, document 
delivery and document distribution. 

It further would be desirable to provide an Internet-based 
document management system and methods that permit 
users to selectively or automatically filter electronic docu- 
ments during storage to and/or retrieval from, an Internet- 
based storage site. 

It still further would be desirable to provide an Internet- 
based document management system and methods that 
permit users to collaboratively store, retrieve, modify and 
then return an electronic document to an Internet-based 
storage site. 

It yet further would be desirable to provide an Internet- 
based document management system and methods that 
enable the transaction logging and accounting functions 
needed for multi-user collaborative electronic document 
manipulation, for example, so that revisions to a document 
may be tracked. 

It also would be desirable to provide an Internet-based 
document management system and methods that enable 
tracking of transactions performed on a document for billing 
purposes, and which provide needed access-control 
protocols, for example, so that specific users' privileges with 
respect to a document may be defined. 

SUMMARY OF THE INVENTION 

In view of the foregoing, it is an object of this invention 
to provide a document management system and methods 
that permit electronic documents to be made available for 
use on open systems, such as the Internet, and to be accessed 
using previously known web browser — without the need for 
a specialized client application. 

It also is an object of the present invention to-provide an 
Internet-based document management system and methods 
that permit users to access a plurality of services supported 
by a common Internet-based database, including document 
storage, collaborative file sharing and workflow, document 
delivery and document distribution. 

It is a further object of this invention to provide an 
Internet-based document management system and methods 
that permit users to selectively or automatically filter elec- 
tronic documents during storage to and/or retrieval from, an 
Internet-based storage site. 

It is another object of the present invention to provide an 
Internet-based document management system and methods 
that permit users to collaboratively store, retrieve, modify 
and then return an electronic document to an Internet -based 
storage site. 
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It is a further object of this invention to provide an FIG. 7 is a flowchart depicting the process of logging a 

Internet-based document management system and methods storage transaction; 

that enable the transaction logging and accounting capabili- pi G g j s a diagram of the service and service provider 

ties needed for multi-user collaborative electronic document architecture* 

manipulation, for example, so that revisions to a document < rt . ' „ , , . . . . , . ' 

may be tracked 9 is a flowchart depicting registration and authenti- 

It is a still further object of the present invention to catlon P rocesses i 

provide an Internet-based document management system FIG- 10 is a flowchart depicting the logon process; 

and methods that enable tracking of transactions performed FIG. 11 is a flowchart depicting a session management 

on a document for billing purposes, and which provide 1Q process; and 

needed access-control protocols, for example, so that spe- FIGS UA and UB ^ flowcharts depicting the notifi- 

dffine U d prmlegCS ^ rCSpCCt t0 a document te cation request and delivery processes. 

These and other objects of the present invention are DETAILED DESCRIPTION OF THE 

accomplished by providing an Internet-based document 1$ INVENTION 
management system and methods wherein an electronic 

document may be stored on an Internet-accessible server and The present invention is directed to apparatus and meth- 
accessed using a previously known web browser, down- ods for managing electronic documents over the Internet, 
loaded for review or manipulation, and then returned to the Specifically, the present invention comprises an Internet- 
server for access by further users. In.accordance with the accessible server programmed to provide a plurality of 
principles of the present invention, the server is programmed document management services, including document stor- 
with several routines that perform numerous functions, age and retrieval, collaborative file sharing and workflow 
referred to hereinafter as "services," that provide a full- services for electronic documents, an electronic document 
featured document management system. delivery service, and a document distribution service. In 
In a preferred embodiment, the document management „ accordance with the principles of the present invention, 
system is programmed to provide a plurality of services mese semces are supported by a common database system 
supported by a common database and document store. These ^ at P"* 1 * interfaces to the multiple services to be accessed 
services preferably include storage and retrieval services to usi f S Previously known web browsers, and without a spe- 
and from an Internet-based storage site, an electronic docu- ciahzcd clienl application, 
ment delivery service, a collaborative file sharing service 3Q System Architecture 

and a workflow service, and a document distribution service. Referring to FIGS. 1A and IB, illustrative architecture 

The server also preferably is programmed to perform a suitable for implementing the system and methods of the 

security function, to verify or define a requestor's ability to present invention is described. In FIGS. 1A and IB, this 

access an electronic document, a filtering function that architecture comprises personal computers 10 and 11 

performs selective or automatic filtering of documents dur- 35 coupled through an open network, such as Internet 15, to 

ing storage to and/or retrieval from the storage site, and document management services ("DMS") system 17. DMS 

accounting functions that enable detailed accounting of, for system 17 comprises server computer 20, which in turn, 

example, usage of storage on the server, number of accesses, comprises or is coupled to DMS database 25, store 30, 

etc. In addition, the system may permit multiple service notification server 35 and public key infrastructure server 

providers to utilize common document management ser- ^ 40. 

vices of a server, while appearing to end-users as separate Personal computers 10 and 11 are connected using dedi- 

dedicated websites. ca ted lines or dial-up connections to the public standard 

BRIEF DESCRIPTION OF THE DRAWINGS telephone network ("PSTN") to an open network, such as 

m A , . . . Internet 15. While Internet 15 is depicted as a single entity, 

Tne above and other objects and advantages of the it ^ of cou ^ be underetood mat Inter net 15 comprises a 

invention wdl be apparent upon consideration of the fol- riad of uter networks connected by bridges, routers, 

lowing detailed description, taken m conjunction with the ^ ^ fc COQStantl evolvin M defined hereinj the term 

accompanying drawings in which like references refer to « Interner refers not onl to me Internet ^ its prese nt form, 

like parts throughout, and in which: ^ ^ ^ cnangeSj addilions and mtur e embodi- 

F1GS. 1A and IB are block diagrams illustrating the 5Q m ents of the Internet. Each of personal computers 10 and 11 

architecture of a document management service (DMS) pre ferably is connected to Internet 15 through an Internet 

system constructed in accordance with the principles of the Service Providcr («ISP»), and includes a web browser, such 

present invention; as thc a f orem entioned Internet Explorer 4.0® or Netscape 

FIG. 2 is a schematic diagram of the components of DMS Navigator®. Personal computers may be standalone 

database 25 of the present invention; 55 computers, or may be connected to the Internet through a 

FIG. 3 depicts an illustrative hierarchy for file storage of local area network (not shown). Personal computers 10 and 

electronic documents under the control of server computer n m ay be IBM personal computers, or take the form of 

20; other devices capable of establishing a connection to the 

FIG. 4 is a simplified flowchart depicting the steps of Internet, including TV set-top boxes, handheld devices, 

using the document management capabilities of DMS sys- 60 Personal Digital Assistants (PDAs) or cellular telephones, 

tem 25 of the present invention; Server computer 20 is coupled to, and communicates 

FIG. 5 is a detailed flowchart depicting the process of asynchronously with, Internet 15, and includes a domain- 
storing an electronic document in the DMS system of the specific digital certificate to enable secure communications, 
present invention; Server computer 20 preferably is programmed as a web 

FIG. 6 is a detailed flowchart depicting the process of 65 server, e.g., to run Hyper Text Transfer Protocol ("HTTP") 

retrieving a document stored in the DMS system of the and with Document Management Services ("DMS") system 

present invention; software constructed in accordance with the present inven- 
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lion. In a preferred embodiment, the DMS software of the stored in the DMS system. Public key infrastructure server 

present invention runs on the web server through a Common 40 ("PKT'), which also may comprise software running on 

Gateway Interface (CGI). server computer 20 or on one or more separate computers 

This enables DMS system 17 to interact with users connected to server computer 20, provides digital certifi- 

through a web browser, rather than requiring specialized 5 catcs t0 use* 5 °f tne DMS system. The digital certificates 

client software. In particular, a user enters information into mav ^ used by the users to digitally sign documents for the 

a form displayed in a web browser. The information is purpose of non-repudiation, 

transferred to server computer 20 using HTTP, and is made DMS system 17 of FIG. 1A illustratively is depicted as 

available to the programmed routines executing on server having a single server computer 20, but also may comprise 

computer 20 through the CGI. Alternatively, the DMS 10 multiple server computers for use in high load scenarios. As 

software of the present invention may be implemented as shown in FIG. IB, when more than one server computer is 

"servlets," i.e., routines, typically written in the Java pro- used, load balance appliance 45 may be employed to balance 

gramming language, that run on a web server. Use of servlets traffic between server computers 20A and 20B. Load balance 

also permits users to interact with DMS system 17 through appliance 45 may comprise software running on the server 

a web browser. 15 computers 20A and 20B. Alternatively, load balance appli 

While the present invention is described in the context of ance 45 may comprise software running on a separate 

web browsers running on personal computers to access the computer (not shown), which is in turn connected to server 

DMS system, other devices and software may be used. In computers 20A and 20B. ] 

general, any software capable of communications with the Referring to FIG. 2, DMS database 25 is described in 

DMS system, and of displaying web pages may be used to 20 greater detail. Database 25 includes a plurality of tables 

access the DMS system. Additionally, as used herein, the 61-64 and 66-68 that maintain information on documents 

term "web browser" includes previously known browsing stored in store 30. Each of tables 61-64 and 66-68 may in 

software, as well as "applets", such as Java applets, that may turn consist of multiple tables. Document information tables 

be downloaded from the DMS system, and temporarily 61 have entries for a number of document-related 

executed within the context of the web browser. 25 parameters, including: information on a document's parent 

Database 25, which may be a relational database, stores: document group; information on the document instances; 

data concerning documents controlled by server computer information on the transport method to be used for retrieval 

20 and stored in store 30 (hereinafter, referred to as "meta- of a document instance; information on the priority of the 

data'*), such as annotations, instructions, characteristics, etc.; document; expiration information: the date and time when a 

user and account data; transaction data; notification data; 30 document instance is changed from "active" status to 

and authorization data, all as described in greater detail "archived" status; workflow information for a document 

hereinafter. Database 25 may be implemented on server instance; security information; document rights; and docu- 

computer 20 or on a separate computer connected to server rnent group rights. 

computer 20. 35 User information tables 62 have entries for information 

Store 30 is connected to server computer 20 and stores relating to users registered to access and use the DMS 

electronic documents (or "files"). Store 30 provides a stor- system, including: the name of the user; logon information 

age mechanism for storing electronic documents, and may f° r tne user* e.g., user ID and password; user notification 

comprise one or more hard drives, optical drives, RAIDs, information, e.g., notification address and transport type; 

etc., and further may comprise one or more stores supporting billing code information; information on the user's account, 

different types of storage media. Store 30 also may comprise where each user account is unique to a service account and 

remote storage, in which the file is stored on a remote DMS user; user session information; and user group information, 

server. If multiple stores are used, DMS system 17 prefer- i.e., information on the group of users that the user is a part 

ably includes a configurable algorithm to decide in which of, including the name of the group, the state of the group, 

store a document will be placed, thereby evenly distributing 45 me group's security information, and document rights for 

document storage among all stores. the group. 

Store 30 preferably comprises either a relational database, Account information tables 63 have entries for infonna- 
where the electronic documents and information about the tion relating to users registered to access and use the DMS 
document is stored in the relational database, or a file system, including: service provider identification; pricing 
system. If store 30 comprises a relational database, a unique 50 pl an for each service provider; and billing information such 
key to the document is generated and indexed, as may be as the user's credit card number and the billing format (e.g., 
appropriate for storage of smaller files (e.g., <1 KB). If store monthly); an optional customized URL for each service 
30 comprises a relational database, then entries in the provider; a logo for each service provider, to customize the 
relational database may include a storage type, a storage user interface; and license agreement information so that a 
path (i.e., a description of location), a name, a maximum size 55 service provider can customize the license agreement 
and a state value. When store 30 comprises more than one between the service provider and users, 
store, the state value for each store may be set to "active" or Administrative information tables 64 have entries that 
"inactive" and documents cannot be stored in an "inactive" enable a registered user to review and track activity for a 
store. If store 30 comprises file system storage, the file user's account, including: information on the system admin- 
system may assign a unique name to each document and the 60 istrator's rights; information on logging errors; information 
document is stored directly on the hard drive, optical drive, on logging transactions; and country and language informa- 
etc, as may be appropriate for large files. tion (e.g., for a system running in the United States, the 

Notification server 35, which may comprise software default language is English), 

running on server computer 20 or on one or more separate Notification information tables 66 maintain information 

computers connected to server computer 20, dispatches 65 necessary to generate a notification message, and include 

notifications, e.g., via voice message, e-mail, pager, etc., to entries for notification transport type, i.e., e-mail, facsimile, 

users of DMS system 17 concerning the status of documents voice, or pager; information on the status of the notification, 
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i.e. pending, sent, failed; the recipient's notification identi- 
fication; priority information; and optionally, the scheduled 
date/time for delivery. 

Transaction information tables 67 record data relating to 
each transaction occurring on the DMS system, and include: 5 
the identification of different transaction types; status infor- 
mation for each transaction; and billing information for each 
transaction type. 

Security information tables 68 include entries for 
security-related parameters, such as: the names of Certificate 10 
Authorities, i.e., trusted third-party organizations that issue 
digital certificates (an attachment to an electronic message 
used for security purposes); information on different types of 
digital certificates; information on Authorized User certifi- 
cates; and notarization information. 15 

Referring now to FIG. 3, an illustrative hierarchical 
storage scheme for storing electronic documents on store 30 
of DMS system 17 is described. Each user of DMS system 
17 preferably has access to one or more document groups 
70, where each document group comprises a collection of 20 
document objects 72A and 72B. One document may belong 
to one, many or no document groups. Each document group 
70 has a name, a description, and a service defined type for 
defining the document type (e.g., word processing file). A 
document group may have one or more parent document 25 
groups. The document groups preferably have extensible 
property types. 

Document objects 72A and 72B represent a generalized 
high level description of a document, and consist of a 3Q 
document name. Document objects also may have exten- 
sible property types. 

Document instances 73A, 73B and 73C correspond to 
specific instances of a document, and each include details 
about the document, a reference to the document, a docu- 35 
ment state, description, size, priority, encryption type and 
expiry date. The default document states are "pending," 
" active ," "archived" and "deleted." Document states are 
extensible by service. A document state log is kept to track 
when a document instance has changed state, as described ^ 
hereinbelow. 

DMS system 17 also preferably supports multiple ver- 
sions of documents, for example, versions 74A and 74B. A 
document version object is employed in document informa- 
tion tables 61 of database 25 and is used to maintain version 4S 
relationships between document instances of a given docu- 
ment. Each document version instance 74A and 74B 
includes a reference to the parent and child document 
instance, a version name and a unique version ID. 

Document records are created in DMS database 25 the so 
first time a new document is stored on DMS system 17. 
Document instance records are created when new docu- 
ments or new versions of existing documents are stored to 
the DMS system. Document group records may be created 
when logical collections of documents are stored at the same 55 
time and it is desired to maintain the relationship between 
the documents. Also, according to the authorization infor- 
mation submitted by a document originator, new document 
rights, document group rights and document instance rights 
are created for the document. A document store record eo 
references a document instance and a store and includes a 
unique key/name to the document's storage location. 

In a preferred embodiment, documents stored in the DMS 
system are monitored by a document state process that 
automatically modifies the state of a document instance 65 
based on its current state, the active date/time, and expira- 
tion date/time. Slates for a document instance include 
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"pending," "active," "archived," "canceled" and "deleted." 
Each default state change in a document instance is logged 
to the DMS database, and may result, for example, in a 
billable transaction. 

Document instances with a "pending" state have an active 
date/time that specifies the time at which the state of the 
document instance should be changed to "active." A "pend- 
ing" document is not available to anyone except the Origi- 
nator. 

Document instances marked "active" are accessible by all 
Authorized Users. If a document instance has an expiration 
time, then the status is changed from "active" to "archived" 
when the expiration time is reached. At this point, document 
instance rights are removed for all Authorized Users except 
the Originator. 

Document instances marked "archived" are accessible 
only to the Originator. The state of these documents is 
changed to "deleted" after a pre -determined amount of time. 
At this time, the physical file corresponding to the document 
instance is removed/deleted from storage and the corre- 
sponding document store record is deleted. Document 
instances marked deleted are only available for tracking and 
billing purposes. These document instances are removed 
from DMS database 25 only when the corresponding trans- 
action log is billed and removed from database 25. 

Document instances are marked "canceled" when an 
Authorized User (typically the Originator) forces a docu- 
ment to expire before the expiration time. Canceled docu- 
ment instances then are treated like archived document 
instances. 

DMS system 17 also may provide a notarization feature, 
where each document instance is notarized by the DMS 
system. A digital notarization is used to authenticate an 
identifiable set of data at a given time. A simple notarization 
scheme, for example, involves creating a digital fingerprint 
(or digest) of a document, by using a one-way hashing 
algorithm, adding a timestamp, and then signing the result- 
ing data with a private key. DMS system 17 may be 
configured to support multiple notarization schemes by 
assigning a notarization type to each digital notarization. A 
digital notarization object may be created, containing a 
reference to a document, document instance, document 
group, notification or transaction. - 

Document Storaqe And Retrieval Processes 

Referring now to FIG. 4, the basic processes of storing 
and retrieving an electronic document to DMS system 17 are 
described. The series of basic steps described with respect to 
FIG. 4 involve interaction between an Originator's computer 
(e g., personal computer 10), DMS system 17, and one or 
more Authorized Users (e.g., personal computer 11). Each of 
the services provided by DMS system 17 includes one or 
more of the steps depicted in FIG. 4, and in accordance with 
the present invention, each of those steps may involve 
performing further functions, such as filtering and account- 
ing functions, specific to a particular service. In accordance 
with the principles of the present invention, billable services 
are made available on DMS system 17 to a specific user, 
singly or in combination, by one or more service providers. 
Preferably, each of the steps described in FIG. 4 is per- 
formed using secure protocols. 

FIG. 4 is now illustratively described in overview with 
respect to a collaborative file sharing service of DMS system 
17. In this service, an electronic document to be stored is 
created by an Originator using a previously known word 
processing, image or spreadsheet client application, and then 
uploaded and stored in DMS system 17. The electronic 
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document then may be retrieved by one or more Authorized 
Users, as defined by the Originator during the storage 
process. After an Authorized User has modified the 
document, it is returned to store 30 of the DMS system. In 
accordance with the principles of the present invention, each 
transaction involving the document is logged in the trans- 
action tables of DMS database 25, for example, for billing, 
reporting, and tracking purposes. 

More particularly, at step 80, an Originator uses a previ- 
ously known client application, such as a word processing, 
image generation application, spreadsheet, etc., to create an 
electronic document. Illustratively, the document may con- 
sist of a business plan and. appendices for a start-up com- 
pany. The Originator then connects to the Internet using his 
or her web browser and enters the URL for the DMS system. 
Once connected to the DMS system website, at step 81, the 
Originator initiates a user session with DMS system 17 
using a logon process, described hereinbelow. 

The Originator then fills out appropriate forms indicating 
a desire to upload the previously created electronic docu- 
ment to the DMS system, and at step 82 defines a list of 
Authorized Users who may access the document. The Origi- 
nator specifies the types of access that each Authorized User 
is to receive, and metadata concerning the document (e.g., 
expiration date, etc.). Thus, for example, some Authorized 
Users may be granted access only to retrieve and review a 
document, while others are granted access to retrieve and 
modify the document. The specific access rights granted to 
each Authorized User are recorded in the document tables of 
DMS database 25, and the transaction is logged in the 
transaction tables of DMS database 25. 

At step 83, the Originator requests that the document be 
uploaded and stored in store 30 of the DMS system. Appro- 
priate records are generated in the document tables of DMS 
database 25, and the transaction is logged in the transaction 
tables of DMS database 25. At step 85, the document is 
uploaded, for example, using HTTP or FTP, and stored in 
store 30. During the upload process, at step 84, the document 
optionally may be automatically or selectively filtered in 
accordance with routines appropriate for the service being 
performed. For example, the document may be automati- 
cally compressed or encrypted, or at the Originator's 
request, converted to a particular file format suitable for the 
Authorized Users (e.g., converted from WordPerfect® to 
Microsoft Word). Other forms of filtering may include 
formatting, translating or virus checking. Both the storage 
and filtering step, if performed, are logged to the appropriate 
tables in DMS database 25. 

At step 86, notification server 35 generates notification 
messages to the Authorized Users informing those Users that 
the document is available in store 30. The notification server 
also may provide a notification to the Originator that the 
notifications to the Authorized Users have been sent or 
delivered, as described hereinbelow with respect to FIGS. 
12Aand 12B. Issuance of any notifications to the Originator 
and Authorized Users are logged in the Notification tables 
and Transaction tables of DMS database 25. At any time 
after the document has been stored to store 30 at step 83, the 
Originator may terminate his or her user session. 

Once an Authorized User receives the notification that the 
document is available for retrieval from store 30, for 
example, by receipt an e-mail message or voice message, the 
Authorized User logs into the DMS system using a previ- 
ously known web browser to create a new user session at 
step 87. The Authorized User may then request retrieval of 
the document from store 30, at step 88, and any automatic 
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filtering, or filtering selected by the Authorized User, may be 
performed during the document download process at step 
89. The document is then downloaded to the Authorized 
User at step 90. Each transaction is logged to the appropriate 

5 tables of DMS database 25. 

In the context of collaborative file sharing, the Authorized 
User may either "get" a copy of the document, thus leaving 
the document available for retrieval by other Authorized 
Users to download and modify, or may "check-out" the 

10 document from store 30. If the Authorized User elects to 
"check-out" the document, only that Authorized User has 
the right to later "check-in" the document. Whether an 
Authorized User has rights to "get" or "check-out" a docu- 
ment depends upon the access rights granted by the Origj- 

15 nator when the document is first stored in the DMS system. 
In a preferred embodiment, the Originator retains the rights 
to later change those access rights. As indicated by return 
arrow 91 in FIG. 4, after an Authorized ^User has checked out 
and modified the document, he or she may check in the 

20 modified document to the DMS system, and the modified 
document is assigned a new version identifier in the docu- 
ment tables of DMS database 25. 

In the context of a workflow service provided by DMS 
system 17, a workflow table may be associated with a 

25 document in DMS database that specifies multiple tasks to 
be performed in sequence by the Authorized Users. In this 
case, the Originator may associate or import a series of task 
descriptions stored in DMS database 25 with a document 
and a list of Authorized Users responsible for performing 

30 those tasks. After an Authorized User retrieves the 
document, performs the task assigned to him or her, and 
returns the document to store 30, notification server 35 
generates and sends an appropriate notification to the Autho- 
rized User responsible for the next task in the workflow. 

In the context of electronic document delivery, the Origi- 
nator may specify one or multiple Authorized Users who are 
permitted access to the document. In this case, notification 
server 35 generates appropriate messages to the Authorized 

^ User(s) via the selected transport mechanism notifying those 
Users that the document is available in store 30. The 
Authorized Users may then initiate User Sessions to retrieve 
the document, including any specified automatic or user 
selected filtering requested for the document. 

4S In the context of a document distribution service, the 
document is made available in store 30 to one or more 
Authorized Users, who may or may not be known to the 
Originator at the time that the document is placed in store 30. 
The Authorized Users may initiate User Sessions to retrieve 

50 the document, including any specified automatic or user 
selected filtering requested for the document. This service 
could be used, for example, to electronically distribute a 
copyrighted book, by permitting users who pay for the book 
to access and download the book. 

55 Referring now to FIG. 5, a detailed flowchart for the 
process of uploading and storing a document in DMS system 
17 is described, corresponding to steps 81-86 of FIG. 4. The 
Originator first logs on and creates a user session as 
described hereinafter with respect to FIGS. 10 and 11. The 

60 Originator now may upload and store one or more electronic 
documents and information pertaining to the Authorized 
Users for those documents to DMS system 17, preferably 
using a secure Internet protocol, such as Secure Socket 
Layer ("SSL") at step 100. 

65 The Originator may "package" a document prior to 
uploading to the DMS system, for example, using a com- 
pression routine, encryption routine, or by adding a digital 
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signature using applications available on the client 
computer, e.g., personal computer 10. Alternatively, such 
"packaging" may be automatically (or selectively, at the 
Originator's request) performed by DMS system 17 as part 
of a filtering process during upload and storage of the 
document at step 102. 

Where an encryption filtering function is employed, the 
document may be encrypted using a symmetric algorithm 
with a unique session key. As will of course be understood, 
any symmetric cipher may be used to encrypt the file. The 
session key may be generated using unique information 
about the file (e.g., Document Instance ID, User ID, date/ 
time information) and optionally, session specific informa- 
tion provided by the user. In the case where the Originator 
provides information (e.g., a password or code), an Autho- 
rized User attempting to retrieve the file must provide the 
same information to permit the DMS system to regenerate 
the session key. Based on the packaging type (if any) of the 
document and the storage encryption type, the document 
instance encryption type is set. 

At step 101, the Originator may designate the Authorized 
Users for the document, and the access rights to be granted 
to those Authorized Users. The Authorized Users may be 
identified using a public identifier, e.g., User ID, certificate, 
or notification address. The list of Authorized Users may 
include users who are not already registered users of a 
service provided by the DMS system, authorizing those 
non- registered users with selected rights with respect to the 
document. For example, an Authorized User only may be 
allowed to view a document, but not be allowed to edit the 
document. Additionally, an Authorized User may be granted 
access to a document only for a limited period of time. The 
Authorized User's rights also may be implied by the service 
selected. 

Metadata, comprising information about the document 
itself, also is uploaded and stored in the document tables of 
DMS database 25 at step 100. Metadata that the Originator 
may upload into the DMS system includes information on: 
priority; subject; message; expiration dateAime of the docu- 
ment; notification scheduling; confirmation notification; a 
password protect flag; access control; and filtering request 
flag. The document and all related data are uploaded and 
stored to DMS system 17 over secure standard protocols 
such as SSL/HTTP and SSL/FTP. 

At step 101, the system determines whether the Originator 
has specified any Authorized Users. If none are specified (or 
all Authorized Users have already been confirmed), the 
document and metadata are stored in the DMS system at step 
103, after any optional automated or requested filtering is 
performed at step 102. Appropriate transactions are logged 
to DMS database 25 at step 104 and a status message is 
returned to the Originator at step 105. 

If the Originator specifies an Authorized User (or there are 
remaining Authorized Users to be confirmed), the system 
determines at step 106 if the specified Authorized User is 
registered. If so, then the DMS authorization system, 
described hereinafter, is updated for that Authorized User to 
reflect the access rights specified by the Originator or 
implied by that service at step 107. At step 108, the Autho- 
rized User then may be sent a notification by notification 
server 35 at his or her notification address. The foregoing 
process is repeated for each Authorized User specified by the 
Originator. 

If the Authorized User is not registered with the DMS 
system, the Authorized User is pre- registered with tempo- 
rary credentials at step 109. If the pre-registered credentials 
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are determined by the system to be trusted credentials at step 
110, for example, if a digital certificate issued by a Certifi- 
cate Authority (a trusted third-party organization that issues 
digital certificates) is available, the pre-registered Autho- 

5 rized User's credentials are copied to or referenced by -the 
DMS system at step 111 and are required for the pre- 
registered Authorized User to access the documents. If the 
credentials are not trusted credentials, a unique introduction 
number is generated and stored in DMS database 25 at step 

10 112. The pre-registered Authorized User then must use this 
introduction number to access the documents. 

At step 113, the pre-registered Authorized User is granted 
the appropriate rights in the DMS authorization system. The 
first time a pre-registered Authorized User is introduced to 

15 a DMS service, an account is created for that Authorized 
User. Alternatively, if the pre-registered Authorized User 
already has been introduced to a DMS service by a regis- 
tered user, the existing pre-registered Authorized User is 
simply given authorization to access the new document. At 

20 step 114, the pre-registered Authorized User is sent an 
introduction message explaining how to access the 
documents, and the entire process is repeated for each new 
Authorized User at step 115. 

At steps 107 and 113, Authorized Users are granted rights 

25 using the DMS authorization system, which defines the 
rights users have on particular document objects, document 
instances and document groups. For example, when DMS 
system 17 is used for a document delivery service, the 
following steps occur: 

A document group is created to logically contain the 

documents to be delivered; 
A document object and document instance are created for 
each document; 

35 Document group rights, document instance rights, and 
document object rights are created for the Originator 
and Authorized User. 
For example, with respect to a document uploaded to the 
DMS system, an Originator may have owner rights, retrieval 

40 rights, viewing rights and the right to revoke access by a 
previously specified Authorized User, while an Authorized 
User may have viewing and retrieval rights. 

Referring now to FIG. 6, the process by which an Autho- 
rized User retrieves a document from DMS system 17 is 

45 described. As described hereinabove for the document stor- 
age process, a document may be filtered during the retrieval 
process, e.g., to uncompress or unencrypt a compressed or 
encrypted document. The first step in document retrieval, at 
step 120, is for an Authorized User to receive a notification 

50 informing the Authorized User that the document is avail- 
able on store 30. At step 121, the Authorized User logs on 
to the DMS system, for example, using the DMS system 
URL and a previously known web browser to retrieve the 
document. Alternatively, the Authorized User may access 

55 the DMS system using a URL contained in the notification 
informing the Authorized User that the document is avail- 
able on store 30. Once the Authorized User logs on to the 
DMS system, document retrieval follows one of four pos- 
sible scenarios. 

60 In case A, at step 122, the Authorized User is identified by 
the DMS system as a registered user. In this case, the 
Authorized User submits his credentials at step 123. Once 
the credentials are authenticated, the user is provided access 
to the documents and data at step 124. 

65 In case B, at step 126, the Authorized User is identified by 
the DMS system as a pre-registered Authorized User and the 
service which he or she is accessing requires an introduction 
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Dumber. In this case, the user is supplied with the introduc- 
tion number either through a notification message (see step 
112 of FIG. 5) or by the Originator using a separate channel 
of communication. The user then submits the introduction 
number at step 127. Once the introduction number is 
authenticated, the user is provided access to the documents 
and data at step 124. 

In case C, at step 128, the Authorized User is a pre- 
registered Authorized User and the service that he or she is 
accessing does not require credentials. In, this case, the 
Authorized User may directly access the documents and data 
at step 124. 

In case D, at step 129, the Authorized User is a pre- 
registered Authorized User with trusted credentials 
(corresponding to step 111 of FIG. 5). In this case, the 
pre-registered Authorized User submits the trusted creden- 
tials at 130. Once the credentials are authenticated, the user 
is provided access to the documents and data at step 124. 

In all cases, all of the Authorized User's activities are 
logged in the transaction log at step 125. 

Transaction Logging 

The DMS system of the present invention preferably 
supports an extensible set of transaction types. A core set of 
transaction types is defined by the DMS system and each 
service provided by the DMS system may define additional 
transaction types. Transaction types have the following 
properties: 

Name 

Billing type: "not billable"; "billable by count"; "billable 
by value" 

Each service account may have a separate pricing plan, 
and each pricing plan may have an associated price per 
period (e.g., monthly subscription), as well as a pricing 
mechanism whereby each transaction type is priced for a 
given value of that transaction ("transaction type pricing 
plan"). For example, if the transaction type is document 
storage, then the transaction type pricing plan may include 
the following information: 

Transaction type (e.g., document storage) 

Pricing plan (e.g., monthly) 

Price (e.g., $0.50 per unit) 

Minimum Value (e.g., 0 KB) 

Maximum Value(e.g., 10 KB) 

Minimum chargeable price (e.g., $1) 

Maximum chargeable price (e.g., $5) 

Visibility: Visible or Not visible, identifying whether the 
user can view logged information on this transaction 
type. 

Given the foregoing information, the value of each transac- 
tion may be calculated and logged in the transaction tables 
of DMS database 25 with an associated price. 

Each transaction may be associated to one or more of: 
document; document instance; document group; or a noti- 
fication (i.e., a particular notification message generated by 
the DMS system). Each transaction also may be associated 
with at least one of: a user account or a service account, and 
preferably is timestamped with the date/time of the trans- 
action. Additionally, each transaction may be digitally 
signed by the DMS system. Transactions also may be 
nestable, i.e., each transaction may have a parent transaction 
associated with it. Transactions may be used to form an audit 
trail for a given user, account, document, document instance, 
document group, or notification. Every one of these objects 
preferably has at least one logged transaction linked to it. 

For example, for a New Document transaction in the 
context of a document delivery service, the following data 
may be stored in the transaction information tables of DMS 
database 25: 
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Parent transaction=document delivery 

Transaction type=new document 

Notification ID=null 

Document Instance ID-9812731 
5 Document Group ID-null 

Document ID~2832837 

Account-ID=5632219 

User ID»3878772 
1Q Amount (Value)=l 

Price (Currency)-$0.50 

Date/Time~12:34:43.99 EST Mar. 1, 1999 

Visible«yes 

Status=active 

15 The transaction links the new document to a document ID 
(for the document object) and a document instance ID (for 
the specific instance or version of this document and its 
related details including a pointer to its storage), the account 
ID, and the user ID of the user who did the transaction. 

20 In accordance with one aspect of the present invention, 
the transaction log may be used to generate a billing state- 
ment for each account user. A billing statement can be 
generated for a particular account and particular statement 
period. In addition, the DMS system of the present invention 

25 also allows for user-defined identifiers (billing codes) to 
track and organize user activity. For example, a lawyer 
storing a contract on DMS system 17 may include as part of 
the metadata for the document an identification of the 
client's billing code. 

30 During the process of generating a billing statement, the 
status of each of the transactions included in the billing 
statement are changed from "active" to "archived/' Trans- 
actions marked as "archived" then may be removed from the 
transaction log (for improved search performance of the 

35 main transaction log) and placed into another log (e.g., an 
archived transactions log). Alternatively, transactions 
marked as archived can be automatically set to "delete" after 
a predetermined configurable lifetime. This status change 
from "archived" to "delete" may occur in both the transac- 

40 tion log and the archived transaction log. Transactions set to 
"delete" are automatically deleted after a timeout period. 

Referring now to FIG. 7 the process of logging a storage 
transaction on the DMS system of the present invention is 
described. As explained above, the DMS system offers many 

45 different services, each of which may have transactions that 
are logged and billed. FIG. 7 is a representative example of 
the process of logging one such transaction. 

At step 140, the logging process requires as input: the 
transaction value (amount), transaction type, and pricing 

50 plan. At step 141, the DMS system determines a billing type 
associated with the transaction type. If the transaction is "not 
billable," determined at step 142, the transaction price is set 
to zero at step 143, and transaction visibility is set according 
to the pricing plan at step 144. If the transaction type's 

55 billing type is "by count," determined at step 145, then the 
record for that range is retrieved from DMS database 25 at 
step 146. The transaction price is set at step 147 and 
visibility is set according to the pricing plan at step 148. 
If the billable type is "by value", determined at step 149, 

60 then the transaction type pricing plan is retrieved from DMS 
database 25 at step 150. In an example in which the 
transaction consists of storing a 1.5 MB document to the 
DMS system, the transaction type is "document storage" and 
the value is 1.5 MB. This transaction type is billable "by 

65 value" and there are two priceable value ranges: 0-1 MB and 
>1 MB. TTie transaction type pricing plan for the first range 
would include the following information: 
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Plan name (e.g. "Gold plan") 
Storage by size 
Price=$0.50 
Minimum Value=0 MB 
Maximum Value=l MB 
Minimum Chargeable Price=*$0.15 
Maximum Chargeable Price=Null 
Visibility =visible 

The transaction type pricing plan for the second range 
would include the following information: 
Plan name (e.g. "Gold plan") 
Storage by size 
Price=$0.25 
Minimum Value- 1 MB 
Maximum Value=Null 
Minimum Chargeable Price-Null 
Maximum Chargeable Price=Null 
Visibility -visible 

At step 151, the DMS system begins calculating the 
transaction price by setting the initial transaction price to 
zero. For each value range within the transaction type's 
value, determined at step 152, the following process is 
repeated: At step 153, it is determined if value >=maximum 
value. If so, the raw price is calculated as (maximum 
value — minimum value)xprice at step 154. If not, raw price 
is calculated as (value — minimum value)xprice at step 155. 
If raw price >-maximum chargeable price, determined at 
step 160, raw price is set to maximum chargeable price at 
step 161. If raw price <maximum chargeable price and if raw 
price <=minimum chargeable price then raw price is set to 
minimum chargeable price at step 163. The transaction price 
is set to transaction price +raw price at step 164. Therefore, 
continuing with the example, for a 1.5 MB file, the final 
transaction price would be $0.50 (1 MBx$0.50)+$0.125 (0.5 
MBx$0.25)=$0.625. 

After the process is repeated for each value range, the 
transaction price is set at step 165. Transaction visibility is 
set according to the pricing plan at step 166, and all of the 
information is logged into the transaction log, completing 
the logging process. 

Service And Service Provider Architecture 

Referring to FIG. 8, an illustrative service and service 
provider architecture for DMS system 17 of the present 
invention is described. In the context of this disclosure, a 
"service provider" is an entity that resells document man- 
agement services available on a DMS system constructed in 
accordance with the principles of the present invention, and 
need not be an ISP. 

DMS system 17 provides and supports a number of 
different services, as described hereinabove. Each service 
provides a unique interface to the DMS system and a unique 
way of interacting with the DMS system. Illustrative 
examples of DMS system services include secure document 
delivery 168a, secure document storage 168b, secure col- 
laborative file sharing 168c, etc. Each service has a unique 
interface that limits how a user may interact with the DMS 
system. For example, a user of a storage service cannot 
cause DMS system 17 to send a notification to another user, 
whereas such functionality may be automatically included in 
a delivery service. 

The services interfaces also permit users to interact with 
DMS system 17 using client applications specific to the 
service to be performed. For example, a web browser may 
be used to make requests to DMS system 17 using HTTP 
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over Secure Sockets Layers (SSL) protocol, and a response 
may be returned in Hyper Text Markup Language 
("HTML"). A word processor application may make a 
request to DMS system 17 using HTTP over SSL and a 

5 response may be returned in Extensible Markup Language 
("XML"). Each DMS service may respond to requests for 
data using different formats, e.g., HTML, XML, etc. A DMS 
service also may respond to requests by structuring the data 
differently according to a service provider's preferences. 

10 Service providers 167a-167c in FIG. 8 each provide a 
DMS service using DMS system 17. In accordance with one 
aspect of the present invention, DMS system 17 may include 
customization functions, that permit different service pro- 
viders to access a single DMS system, but create the 

15 appearance of separate dedicated server computers. For 
example, by accessing a document delivery service with a 
service account provided by ACME Document Delivery, the 
user will view ACME's corporate logo in the data returned. 
This may be accomplished, for example, using a "logo" 

20 parameter, stored in account information tables 64 (see FIG. 
2), which identifies a particular service provider's corporate 
information to be displayed to a user account administered 
by that service provider. There may be one or many service 
providers 167a-c for each of one or more services on a 

25 single DMS system. 

DMS system 17 thus may host services for many different 
organizations. Users that have a registered service account 
may use DMS system 17 to access any service for which 
they are registered. Moreover, a registered user may have 

30 more than one DMS service account, enabling that user to 
use the same service from more than one service provider 
167fl-c or use different services from different service 
providers X67a-c, or any combination thereof. Because a 
service account contains both a service and a service pro- 

35 vider 167a-c, billable activity may be tracked by service and 
by service provider, thus enabling multiple organizations to 
appear to the end-users (i.e., registered users) to have a 
"dedicated" virtual DMS service on the same DMS system 
17. 

40 User Registration and DMS Access 

The user registration and authentication processes for 
registering as a user of DMS system 17 are now described. 
As described hereinabove, many of the services offered by 
the DMS system of the present invention require a user to 

45 have a user account, and information on each user account 
is stored in the account information tables of DMS database 
25. In a referred embodiment, a user may obtain a user 
account either by: 1) registration and authentication or 2) 
through introduction by another registered user. 

50 Each user account is unique to a service account and user; 
information on each service account also is stored in DMS 
database 25. A service account comprises a service, a service 
provider, a pricing plan for every transaction the user does 
with an account, a limit plan that limits the use of an account 

55 (e.g., a limit on the maximum file size that can be uploaded 
into the DMS system), a feature plan for customizing the 
features available for each service (e.g., disabling the sched- 
uled delivery feature of the document delivery service), and 
billing information (billing address and payment 

60 information). 

Referring to FIG. 9 the registration and authentication 
processes used by a user to gain access to DMS system 17 
are described. At step 170, the registrant accesses the DMS 
system registration interface, for example, using a web 

65 browser to access the DMS system's registration interface 
URL. Next, at step 171, the registrant selects a DMS service 
for which he or she wishes to be registered. At step 172, the 
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DMS determines whether the registrant already has an 
existing DMS service account. 

If the registrant already has a DMS account, registration 
for a new service requires that the registrant provide his or 
her user credentials at step 173 and then authenticate those 5 
credentials at step 180. If the registrant has no pre-existing 
account, determined at step 172, the registrant is requested 
to provide personal information, such as name, address, 
notification address (e.g., e-mail address, telephone number, 
IP address), payment information, etc. at step 174. At step 10 
175, the DMS server computer processes and verifies the 
registration information. If the information is not success- 
fully verified at step 176, the registrant is informed that 
insufficient information has been provided, at step 186, and 
the registrant is requested to resubmit the information. 15 

If the information is successfully verified, the registrant is 
provided with user credentials over a secure link at step 177. 
User credentials, which may consist, for example, of alpha- 
numeric user IDs, alphanumeric passwords, digital 
certificates, and/or notification addresses, permit the user to 20 
securely access documents, upload documents, view autho- 
rized information on documents, digitally sign documents, 
etc. A user's credentials uniquely identify the user to the 
DMS system. At step 178, the registrant is given instructions 
to authenticate his or her credentials. 25 

Once the registrant is issued credentials, or is determined 
to already have credentials, the authentication process 
begins, at step 179. This may be accomplished by the 
registrant accessing the DMS authentication interface by 
inputting the URL associated with the DMS authentication 30 
interface into his or her web browser. Once the registrant is 
successfully authenticated, at step 180, the registrant's new 
service account is ready for use at step 181. If the registrant 
is not successfully authenticated at step 180, an authentica- 
tion failure is logged at step 182. If the number of authen- 35 
tication failures exceeds a predetermined number, at step 
183, the registrant's ability to authenticate is locked for a 
predetermined period of time at step 184. If the number of 
authentication failures does not exceed the predetermined 
safety limit, the registrant is prompted to authenticate again 40 
at step 185. 

Referring now to FIG. 10, after a user has become 
registered and has authenticated his or her credentials with 
the DMS system, the user then may access the services 
provided by the DMS service by logging on to the DMS 45 
system. A user first accesses the DMS logon service at step 
190, for example, using a web browser to access the URL 
associated with the DMS logon service. The user then 
supplies his or her credentials at step 191, and the DMS 
checks to see if the credentials are valid at step 192. If the 50 
credentials are valid, a user session is created at step 193 and 
the user is given access to the DMS system at step 194. 

If the credentials are not valid, a logon security event 
(noting that there has been a failed logon attempt) is logged 
at step 195. The DMS checks to see if the number of logon 55 
security events exceeds a predetermined number at step 196. 
If that number is not exceeded, an error message is sent to 
the user and the user is permitted to retry the logon process 
at step 197. If the number of logon security events exceeds 
the predetermined number, the user is locked out of the 60 
system at step 198 and a message to that effect is sent to the 
user at step 199. If the user makes a request to the DMS 
system after the current session has expired, he or she will 
be asked to logon again. 

Once a user has successfully logged on, a user session is 65 
logged and stored in DMS database 25. A session comprises 
a unique alphanumeric identifier and a timestamp, and is 
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associated with a specific user account. Each request made 
to the DMS after logging in as a registered user must include 
the correct session password or service will be denied and a 
security event will be logged. Successive security events 
cause an account lockout, preventing the user from gaining 
further access to the DMS system. 

HTTP sessions are stateless, so information on these 
sessions must be maintained in database 25. Communica- 
tions to server 20 contains a session identifier number that 
references session information in database 25, Sessions are 
managed by an automatic process, illustrated in FIG. 11, that 
continually monitors the length of a session to determine if 
a current session is longer than a specific, predetermined 
interval. If there is an active session, determined at step 200, 
the DMS system determines if the session length is greater 
than the predetermined interval, at step 201. If the interval 
has been exceeded, the user session is rendered inactive at 
step 202 and a flag to that effect is entered in the corre- 
sponding database entry. The process is repeated at step 203 
for each active session. Alternatively, a user forced logout/ 
exit also may render a user session inactive and the corre- 
sponding database entry is flagged accordingly. 

Notification Processes 

Referring now to FIGS. 12A and 12B, the notification 
request and confirmation services available on a preferred 
embodiment of DMS system 17 are described. Notification 
messages are generated by notification server 35 in response 
to various user events. For example, when a registrant 
registers for a DMS service, the registrant receives a noti- 
fication with instructions on authorization, as discussed 
hereinabove with respect to step 178 of FIG. 9. 

As another example, when an Originator has created an 
electronic document and uploaded that document to the 
DMS system, Authorized Users having access to the docu- 
ment may receive a notification that the document is avail- 
able to be retrieved (as discussed with reference to steps 108 
and 114 of FIG. 5). In this case, the notification may contain 
instructions on how the document may be retrieved from the 
DMS system. The notification messages are digital and may 
take the form of an alphanumeric message, digital sound, 
digital image or other digital forms. DMS system 17 there- 
fore preferably supports several types of notification trans- 
ports including e-mail, fax, voice messaging and pager. 

With respect to FIG. 12A, the notification request process 
performed by DMS system 17 is described. At step 210, a 
notification message is created by notification server 35 
responsive to some user-initiated event. At step 211, a 
notification request is created that contains some or all of the 
following information: (1) the subject of the message; (2) 
the Originator's notification address (e.g., an e-mail 
address); (3) the notification address of the Authorized 
User(s); (4) the priority of the notification (e.g., high, 
medium, or low); (5) the body of the message, including a 
unique notification identifier created by the DMS system; (6) 
optionally, an indication of the date and time that the 
message should be delivered; (7) a status flag (e.g., 
"pending", "sent", or "failed") indicating the status of the 
notification delivery, initially set to "pending"; (8) the trans- 
port type for the notification (e.g., e-mail, voice message, 
etc.); and (9) a retry counter that tracks the number of times 
that a notification request has been processed (initially set to 
zero, and incremented upon each unsuccessful delivery 
attempt until the notification request status is marked 
"failed.") The notification request is queued, at step 212, 
with a status of "pending," in notification information tables 
66 of DMS database 25. 

The notification delivery process is described with respect 
to FIG. 12B. At step 220, the system iterates through the 
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records in the tables with a "pending" flag. At step 221, 
notification server 35 attempts to deliver the notification 
using the specified transport system for that Authorized 
User. DMS system 17 then checks to see if there is a 
transport rejection, at step 222, for example, if notification 5 
server 35 is not working. If no transport rejection is detected, 
the notification request flag is set to "sent" at step 223, and 
the notification transaction is logged as sent at step 224. 

If a transport rejection is detected, at step 222, a retry 
counter is checked at step 225. If the number of retries does 1Q 
not exceed a predetermined limit, the retry counter is incre- 
mented at step 226 and the notification process begins again. 
If the number of retries exceeds the predetermined limit, the 
notification request flag is set to "failed" at step 227, and the 
notification transaction is logged as "failed," at step 228. At 1S 
step 229, the DMS system checks information on the origin 
of the notification request; where the origin of a notification 
request may be either the DMS system or a system user. 

For example, as described hereinabove, when the notifi- 
cation comprises directions for authorization of a new 2Q 
registrant, the notification is automatically generated by the 
DMS system. However, if the notification is a notification 
that a document has been stored in store 30 for subsequent 
retrieval by Authorized Users, the notification may be ini- 
tiated at the request of the Originator who uploaded the 1$ 
document to store 30. At step 229, if the system determines 
that the origin is a system user (rather than the DMS system), 
a new notification message reporting the failed notification 
delivery attempt is generated and sent to the system user at 
step 230. 30 

It is possible for a notification to be sent, but for the send 
to be unsuccessful, for example, if the notification recipi- 
ent's e-mail address is incorrect For this reason, each 
notification transport that delivers notification messages also 
preferably receives messages that notifications have been 35 
sent successfully but have failed during transport. Each 
notification transport is polled by an automated process for 
any new messages. Upon receiving a failed notification, this 
process determines (if possible) the notification identifier, 
marks the original notification request as "failed" and logs a ^ 
failed notification transaction linked to the original notifi- 
cation request. In addition, if the origin is not the DMS 
system, a notification is generated and sent to the sender 
indicating a failed delivery. 

One skilled in the art will appreciate that the present 4S 
invention can be practiced by other than the described 
embodiments, which are presented for purposes of illustra- 
tion and not of limitation, and the present invention is 
limited only by the claims that follow. 

What is claimed is: 

1. An Internet-based document management system com- 
prising: 

an Internet-based store for storing an electronic docu- 
ment; 

a database programmed to include and access a document 55 
table for storing information about the electronic docu- 
ment and a transaction table that stores information 
about transactions performed on the electronic docu- 
ment by different users of the Internet-based document 
management system; and 60 

a server connected to the Internet -based store and the 
database, the server programmed to receive the docu- 
ment from a remote computer using an Internet proto- 
col and store the document in the Internet -based store, 

wherein the server is programmed to provide a plurality of 65 
services supported by the database, including filtering 
the electronic document before storing the document in 
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the Internet-based store using one or more of: 
compression, decompression, encryption, decryption, 
translation, and formatting. 

2. The Internet-based document management system of 
claim 1 wherein the plurality of services comprises at least 
a document storage and retrieval service and an electronic 
document delivery service. 

3. The Internet-based document management system of 
claim 2 wherein the plurality of services further,comprises a 
collaborative file sharing service. 

4. The Internet-based document management system of 
claim 2 wherein the document management system provides 
a customization function wherein a user is presented with 
corporate information corresponding to one of a plurality of 
service providers employing the document management 
system. 

5. The Internet-based document management system of 
claim 2, wherein the Internet-based store comprises a file 
system. 

6. The Internet-based document management system of 
claim 2, wherein the Internet-based store comprises a hier- 
archical storage system. 

7. The Internet-based document management system of 
claim 1 wherein the database further comprises an account 
information table including accounting data, and the server 
is programmed to apply the accounting data to the informa- 
tion stored in the transaction table to determine a price 
reflecting usage of the document management system. 

8. The Internet-based document management system of 
claim 1 further comprising a notification server that gener- 
ates and dispatches notifications containing information 
about the electronic document using information stored in 
the database. 

9. A method of providing Internet-based document man- 
agement comprising: 

providing an Internet-based store, a database and a server 
connected to the Internet-based store and the database; 

accepting a connection from a first remote computer to the 
server using an Internet protocol; 

receiving an uploaded electronic document from the first 
remote computer to the server using an Internet proto- 
col; 

generating a record in a document table of the database to 
store information about the electronic document; 

generating a record in a transaction table of the database 
to store information about transactions performed on 
the electronic document; 

filtering the electronic document by applying one or more 
of: compression, decompression, encryption, 
decryption, translation and formatting to the document; 

storing the electronic document in the Intemet-based 
store; 

accepting a connection from a second remote computer to 
the server using an Internet protocol; and 

providing to the second remote computer a plurality of 
document management services supported by the data- 
base; 

wherein the transaction table stores information about 
transactions performed on the electronic document by 
multiple users. 

10. The method of claim 9 wherein providing to the 
second remote computer a plurality of document manage- 
ment services supported by the database comprises provid 
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ing at least a document storage and retrieval service and an 
electronic document delivery service. 

11. The method of claim 10 wherein providing to the 
second remote computer a plurality of document manage- 
ment services supported by the database further comprises 
providing a collaborative file sharing service. 

12. The method of claim 9 further comprising providing 
a customization function wherein a user is presented with 
corporate information corresponding to one of a plurality of 
service providers employing the document management 
system. 

13. The method of claim 9 wherein the database further 
comprises an account information table including account- 
ing data, the method further comprising applying the 
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accounting data to the record in the transaction table to 
determine a price. 

14. The method of claim 9 wherein storing the electronic 
document in the Internet-based store further comprises gen- 

5 era ting a record in a document table of the database. 

15. The method of claim 9 wherein storing the electronic 
document in the Internet-based store further comprises stor- 
ing the electronic document in a hierarchical storage system. 

16. The method of claim 9 further comprising generating 
10 and dispatching a notification from the server to the second 

remote computer containing information about the elec- 
tronic document using information stored in the database. 

* * * * * 
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